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Abstract 

Researchers  at  the  Naval  Research  Laboratory 
(NRL)  have  been  developing  a  formal  method,  known 
as  the  SCR  (Software  Cost  Reduction)  method,  to 
specify  the  requirements  of  software  systems  using  ta¬ 
bles.  NRL  has  developed  a  formal  state  machine  model 
defining  the  SCR  semantics  and  support  tools  for  anal¬ 
ysis  and  validation.  Recently,  a  verification  capability 
was  added  to  the  SCR  toolset.  Users  can  now  invoke 
the  Spin  model  checker  within  the  toolset  to  establish 
properties  of  a  specification.  This  paper  describes  the 
results  of  our  initial  experiments  to  verify  properties  of 
SCR  requirements  specifications  using  Spin.  After  re¬ 
viewing  the  SCR  requirements  method  and  introducing 
our  formal  requirements  model,  we  describe  how  SCR 
specifications  can  be  translated  into  an  imperative  pro¬ 
gramming  notation.  We  also  describe  how  we  limit 
state  explosion  by  verifying  abstractions  of  the  origi¬ 
nal  requirements  specification.  These  abstractions  are 
derived  using  the  formula  to  be  verified  and  special  at¬ 
tributes  of  SCR  specifications.  The  paper  concludes 
with  the  results  of  our  experiments  with  Spin  and  a 
discussion  of  ongoing  and  future  work. 

1  Introduction 

For  a  number  of  years,  researchers  at  the  Naval  Re¬ 
search  Laboratory  (NRL)  have  been  developing  a  for¬ 
mal  method  based  on  tables  to  specify  the  require¬ 
ments  of  software  systems  [AF+92,  Hen80].  The 
method,  known  as  the  Software  Cost  Reduction  (SCR) 
method,  was  originally  formulated  to  document  the  re¬ 
quirements  of  the  Operational  Flight  Program  (OFP) 
for  the  U.S.  Navy’s  A- 7  aircraft.  Since  SCR’s  introduc¬ 
tion  more  than  a  decade  ago,  many  industrial  organi¬ 
zations,  including  Lockheed,  Grumman,  and  Ontario 
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Hydro,  have  used  the  SCR  method  to  specify  require¬ 
ments. 

NRL  has  developed  both  a  formal  state  machine 
model  to  define  the  SCR  semantics  [HJL96b,  HJL96a, 
HLK95]  and  a  set  of  software  tools  to  support  analy¬ 
sis  and  validation  of  SCR  requirements  specifications 
[H+95,  HJL96a].  The  toolset  supports  creation  and 
editing  of  an  SCR  requirements  specification,  con¬ 
sistency  and  completeness  checking,  and  simulation. 
Recently,  we  added  a  verification  capability  to  the 
toolset.  After  using  the  tools  to  develop  and  refine 
a  formal  requirements  specification,  a  specifier  can 
now  invoke  the  Spin  model  checker  [Hol91]  within  the 
toolset  to  verify  properties  of  the  specification. 

For  several  years,  formal  verification  of  programs 
has  been  an  active  area  of  research  [Flo67,  CM88, 
MP91a,  MP91b].  Recently,  model  checking  has 
emerged  as  a  practical  method  for  verifying  finite- 
state  system  descriptions,  in  particular,  descriptions 
of  hardware  and  communications  protocols  [CES86, 
Hol91,  Kur89,  McM93].  An  early  effort  to  apply 
model  checking  to  requirements  specifications  was  re¬ 
ported  in  1993  by  Atlee  and  Gannon,  who  used  the 
model  checker  MCB  [CES86]  to  analyze  properties 
of  individual  mode  transition  tables  taken  from  SCR 
specifications  [AG93].  More  recently,  Sreemani  and 
Atlee  [SA96]  used  the  symbolic  model  checker  SMV 
[McM93]  to  verify  that  the  mode  transition  tables  in 
the  original  A- 7  requirements  document  satisfied  as¬ 
sertions  about  combinations  of  modes.  The  latter  ex¬ 
periment  demonstrates  that  model  checking  can  be 
used  to  analyze  moderately  large  requirements  speci¬ 
fications. 

A  major  goal  of  our  work  is  to  generalize  some  as¬ 
pects  of  the  earlier  work  on  verifying  requirements 
specifications.  While  the  work  by  Atlee  et  al.  veri¬ 
fied  properties  of  mode  transition  tables  with  boolean 
input  variables,  the  approach  we  describe  may  be  used 
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to  verify  properties  of  a  complete  SCR  specification. 
Further,  we  allow  variables  to  range  over  arbitrary  (fi¬ 
nite)  domains  such  as  integer  subranges  and  enumer¬ 
ated  values. 

Another  goal  of  our  work  is  to  describe  formally  the 
relationship  between  a  requirements  specification  and 
the  abstract  models  we  verify.  Our  approach  starts 
with  a  requirements  specification,  a  black  box  descrip¬ 
tion  of  all  acceptable  system  implementations  [HM83]. 
Because  existing  verification  methods  do  not  scale  well 
for  such  descriptions  (they  are  too  detailed),  we  verify 
properties  of  more  abstract  models.  Others  have  also 
taken  this  approach.  For  example,  Atlee  et  al.  analyze 
abstract  models,  and  recently  Butler  has  used  PVS 
[ORS92]  to  analyze  abstractions  of  SCR-like  system 
models  [But96].  However,  the  correspondence  between 
these  abstract  models  and  the  requirements  specifica¬ 
tion  is  informal  -  the  correctness  of  the  abstraction  is 
based  on  arguments  that  appeal  to  intuition.  In  con¬ 
trast,  our  approach  is  based  on  principles  that  allow 
us  to  derive  the  abstract  models,  either  automatically 
or  under  user  guidance,  from  the  requirements  speci¬ 
fication  within  a  formal  framework. 

This  paper  describes  the  results  of  our  initial  experi¬ 
ments  to  verify  properties  of  SCR  requirements  specifi¬ 
cations  using  the  Spin  model  checker.  After  reviewing 
the  SCR  approach  to  requirements  specifications  and 
introducing  our  formal  requirements  model,  the  pa¬ 
per  describes  how  SCR  specifications  can  be  translated 
into  an  imperative  programming  notation.  The  paper 
also  describes  how  we  limit  state  explosion  by  veri¬ 
fying  an  abstract  model  of  the  original  requirements 
specification.  Such  abstractions  can  be  derived  using 
the  formula  to  be  verified  and  the  special  attributes 
of  SCR  specifications.  The  paper  concludes  by  pre¬ 
senting  the  results  of  our  experiments  with  Spin  and 
a  discussion  of  ongoing  and  future  work. 

2  Background 

2.1  SCR  Requirements  Specifications 

In  SCR,  the  required  system  behavior  is  described 
by  REQ,  the  required  relation  between  monitored  vari¬ 
ables,  environmental  quantities  that  the  system  mon¬ 
itors,  and  controlled  variables,  environmental  quanti¬ 
ties  that  the  system  controls  [PM95].  To  specify  this 
relation  concisely,  the  SCR  approach  uses  four  con¬ 
structs  -  modes,  terms,  conditions,  and  events.  A 
mode  class  is  a  variable  whose  values  are  system  modes 
(or  simply  modes),  while  a  term  is  any  function  of  mon¬ 
itored  variables,  modes,  or  other  terms.  A  condition 


Old  Mode 

Event 

New  Mode 

TooLow 

@T(WaterPres  >  Low) 

Permitted 

Permitted 

@T(WaterPres  >  Permit) 

High 

Permitted 

@T(WaterPres  <  Low) 

TooLow 

High 

@T(WaterPres  <  Permit) 

Permitted 

Table  1:  Mode  Transition  Table  for  Pressure. 

is  a  predicate  defined  on  one  or  more  system  entities 
(an  entity  is  a  monitored  or  controlled  variable,  mode 
class,  or  term).  An  event  occurs  when  the  value  of  any 
system  entity  changes.  The  notation  “®T(c)  WHEN  d” 
denotes  a  conditioned  event,  defined  as 

®T(c )  WHEN  d  d=  -ic  A  c'  A  d, 

where  the  unprimed  condition  c  is  evaluated  in  the 
“old”  state,  and  the  primed  condition  d  is  evaluated 
in  the  “new”  state.  The  environment  may  change  a 
monitored  quantity,  causing  an  input  event.  In  re¬ 
sponse,  the  system  changes  controlled  quantities  and 
updates  terms  and  mode  classes. 

To  introduce  the  SCR  constructs,  we  consider  a 
simplified  version  of  a  control  system  for  safety  injec¬ 
tion  [CP93].  The  system  monitors  water  pressure  and 
injects  coolant  into  the  reactor  core  when  the  pres¬ 
sure  falls  below  some  threshold.  The  system  operator 
may  block  this  process  by  pressing  a  “Block”  switch. 
The  system  is  reset  by  a  “Reset”  switch.  To  spec¬ 
ify  the  requirements  of  the  control  system,  we  use  the 
monitored  variables  WaterPres,  Block,  and  Reset  to 
denote  monitored  quantities,  and  a  controlled  variable 
Saf etylnj ection  to  denote  the  controlled  quantity. 
The  specification  includes  a  mode  class  Pressure,  a 
term  Overridden,  and  several  conditions  and  events. 

The  mode  class  Pressure,  an  abstract  model  of 
WaterPres,  has  three  modes:  TooLow,  Permitted,  and 
High.  At  any  given  time,  the  system  must  be  in  one 
and  only  one  of  these  modes.  A  drop  in  water  pressure 
below  a  constant  Low  causes  the  system  to  enter  mode 
TooLow;  an  increase  in  pressure  above  a  larger  con¬ 
stant  Permit  causes  the  system  to  enter  mode  High. 
Table  1  is  a  mode  transition  table  which  specifies  the 
mode  class  Pressure. 

The  term  Overridden  is  true  if  safety  injection  is 
blocked,  and  false  otherwise.  Table  2  is  an  event  ta¬ 
ble  which  specifies  the  behavior  of  Overridden.  The 
expression  “®T( Inmode)”  in  a  row  of  an  event  table 
denotes  the  event  “system  enters  the  corresponding 
mode”.  For  instance,  the  entry  in  the  first  row  of 
Table  2  specifies  the  event  “the  system  enters  mode 
High”. 

Table  3  is  a  condition  table  that  specifies  the 
controlled  quantity  Saf  etylnj  ection.  The  table 


Mode  Events 

High  False  @T(Inmode) 

TooLow,  @T(Block=On)  @T(Inmode)  OR 

Permitted  WHEN  Reset  =  Off  @T(Reset  =  On) 

Overridden  True  False 

Table  2:  Event  Table  for  Overridden. 

states  that  “If  Pressure  is  High  or  Permitted  or  if 
Pressure  is  TooLow  and  Overridden  is  true,  then 
Saf  etylnj  ection  is  Off;  otherwise,  it  is  On”. 


Table  3:  Condition  Table  for  Saf ety  Injection. 
2.2  Semantics  of  SCR  Specifications 

The  following  is  an  informal  introduction  to  the 
SCR  formal  model.  For  a  formal  treatment,  see 
[HJL96b], 

The  model,  which  describes  the  system  being  spec¬ 
ified  as  a  finite  state  machine,  includes  a  set  RF  = 
{r i,  r'2,  ■  ■  ■ ,  rn}  of  entities  and  a  special  function  TY 
which  maps  each  entity  to  its  legal  values.  In  the 
model,  a  state  s  is  represented  as  a  function  that  maps 
each  entity  in  RF  to  its  value  in  s. 

Our  formal  model  describes  a  state  machine  Y  as  a 
4-tuple,  Y  =  (S,  so,  Em ,  T),  where  S'  is  a  set  of  states, 
so  £  S  is  the  initial  state,1  Em  is  the  set  of  input 
events,  and  T  is  the  transform  describing  the  allowed 
state  transitions.  In  the  initial  version  of  our  formal 
model,  the  transform  T  is  deterministic.  That  is,  T 
is  a  function  that  maps  an  input  event  and  the  cur¬ 
rent  state  to  a  new  state.  The  system  begins  in  state 
so.  When  an  input  event  signals  a  change  in  a  mon¬ 
itored  quantity,  the  transform  T  specifies  the  value 
of  each  controlled  variable,  term,  and  mode  class  in 
the  new  state.  The  transform  T  is  the  composition  of 
smaller  functions,  called  table  functions.  These  table 
functions  are  derived  from  the  SCR  tables  that  de¬ 
fine  the  controlled  variables,  terms,  and  mode  classes. 
Our  formal  model  requires  that  each  condition,  event, 
and  mode  transition  table  satisfies  certain  properties. 
These  properties  guarantee  that  each  table  function  is 
a  total  function. 

1  To  simplify  the  examples  in  this  paper,  we  assume  a  unique 
initial  state.  The  formal  model  described  in  [HJL96b]  allows 
the  initial  state  to  have  more  than  a  single  value. 


To  compute  an  entity’s  value  in  the  new  state,  the 
transform  T  may  use  the  values  of  entities  in  both  the 
old  state  and  the  new  state.  To  describe  the  entities 
on  which  a  given  entity  “directly  depends”  in  the  new 
state,  we  define  dependency  relations  Dnew,  D0id,  and 
D  on  RF  x  RF.  For  entities  r;  and  rj ,  the  pair  (r;  ,rf)  E 
Dnew  iff  r'j  is  a  parameter  of  the  function  defining  r{; 
the  pair  (r8,rj)  E  D0id  iff  rj  is  a  parameter  of  the 
function  defining  r{;  and  D  =  Dnew  U  D0jd-  To  avoid 
circular  definitions,  we  require  Dfew,  the  transitive 
closure  of  the  Dnew  relation,  to  define  a  partial  order. 

The  assumptions  that  the  table  functions  are  total 
and  that  the  entities  in  RF  are  partially  ordered  guar¬ 
antee  that  the  transform  T  is  a  function  (at  most  one 
new  system  state  is  defined)  and  complete  (for  each 
enabled  input  event,  at  least  one  new  system  state  is 
completely  defined). 

To  illustrate  the  formal  model,  we  reconsider 
the  control  system  for  safety  injection  described 
above.  In  this  system,  the  set  of  entity  names 
RF  contains  the  three  monitored  variables  Block, 
Reset,  and  WaterPres,  the  mode  class  Pressure, 
the  term  Overridden,  and  the  controlled  variable 
Saf  etylnj  ection.  The  type  definitions  are 

TY(Block)  =  {On,  Off} 

TY(Reset)  =  {On,  Off} 

TY(Saf etylnjection)  =  {On,  Off} 

TY(Pressure)  =  {TooLow,  Permitted,  High} 
TY(Overridden)  =  {true,  false } 

The  new  state  dependency  relation  Dnew  for  safety 
injection  system  is 

{ (Saf  etylnjection,  Pressure), 

(Saf  etylnjection,  Overridden), 

(Pressure,  WaterPres),  (Overridden,  Pressure), 
(Overridden,  Block),  (Overridden,  Reset)}. 

By  applying  the  definitions  in  [HJL96b]  to  the  above 
tables,  we  derive  the  following  table  functions  for  the 
mode  class  Pressure,  the  term  Overridden,  and  the 
controlled  variable  Saf  etylnj  ection: 

Pressure’  = 

'  TooLow  if  Pressure  =  Permitted  A 

WaterPres’  <  Low  A  WaterPres  f  Low 

High  if  Pressure  =  Permitted  A 

WaterPres7  >  Permit  A  WaterPres  if  Permit 

< 

Permitted  if  (Pressure  =  TooLow  A  WaterPres7  >  LowA 
WaterPres  if  Low)  V  (Pressure  =  HighA 
WaterPres7  <  Permit  A  WaterPres  f  Permit) 

otherwise. 


Pressure 


Overridden'  = 

'  true  if  (Pressure  =  TooLow  A  Block/  =  On  A 

Block  =  Off  A  Reset  =  Off)  V 
(Pressure  =  Permitted  A  Block7  =  On  A 
Block  =  Off  A  Reset  =  Off) 

false  if  (Pressure  =  TooLow  A  Reset7  =  On  A 

Reset  =  Off)  V 

<  (Pressure  =  Permitted  A  Reset7  =  On  A 

Reset  =  Off)  V 

(Pressure7  =  High  A  Pressure^High)  V 
(Pressure7  =  TooLow  A  Pressure  ^  TooLow)  V 
(Pressure7  =  Permitted  A 
Pressure  ^  Permitted) 

v  Overridden  otherwise. 


Saf etylnjection  = 

(  Off  if  Pressure  =  High  V  Pressure  =  Permitted  V 
/  (Pressure  =  TooLow  A  Overridden  =  true) 

I  On  if  Pressure  =  TooLow  A  Overridden  =  false 


The  system  behavior  described  by  our  model  has  a 
nondeterministic  part  and  a  deterministic  part.  While 
the  transform  T  is  deterministic,  the  input  events, 
which  are  produced  by  the  environment,  are  nonde¬ 
terministic.  The  monitored  variables  involved  in  the 
input  events  may  each  be  represented  as  simple  finite 
state  machines  with  an  initial  state,  a  set  of  possible 
states,  and  a  next-state  relation.  For  example,  the 
monitored  variables  Block  and  Reset  in  the  example 
both  have  Off  as  their  initial  state,  the  set  {Off,  On} 
as  their  possible  states,  and  the  set  {(Off,  On),  (On, 
Off)}  as  the  next-state  relation.  One  possible  model 
for  the  monitored  variable  WaterPres  has  an  initial 
state  of  14,  possible  states  of  {0,  1,2,  .  .  .,2000},  and 
a  next-state  relation  which  only  allows  WaterPres  to 
change  by  10  units  from  one  state  to  the  next,  i.e. , 

{  (z,  x')  |  i  <  \x'  -  x\  <  10,  0  <  x  <  2000,  0  <  x  <  2000}. 

An  important  assumption  of  our  model,  the  One  In¬ 
put  Assumption,  states  that  only  one  monitored  vari¬ 
able  changes  at  each  state  transition.  Using  the  above 
models  of  the  monitored  variables,  we  can  show  that 
when  the  sample  system  is  in  its  initial  state,  all  of  the 
following  input  events  are  enabled:  @T(Block=0n), 
@T(Reset=0n),  and  @T(WaterPres=*),  where  4  < 
x  <  24  and  x  yl  14.  The  One  Input  Assumption  al¬ 
lows  only  one  of  these  input  events  to  occur  at  the 
next  state  transition. 


3  Verification 

This  section  describes  our  use  of  model  checking, 
based  on  state  exploration  methods,  to  perform  veri¬ 
fication.  By  verification,  we  mean  the  process  of  es¬ 
tablishing  logical  properties  of  an  SCR  specification. 


We  specify  the  properties  as  logical  formulae.  In  this 
paper,  we  focus  on  a  class  of  properties  known  as  state 
invariants,  which  assert  the  truth  of  a  predicate  for¬ 
mula  in  all  reachable  states  of  a  system.  In  the  fol¬ 
lowing,  we  assume  that  a  given  SCR  specification  sat¬ 
isfies  application-independent  properties  -  that  is,  the 
specification  is  type  correct,  the  table  functions  de¬ 
rived  from  the  specification  are  total  functions,  etc. 
Such  properties  can  be  established  using  our  toolset. 
(For  details  of  how  these  checks  are  carried  out,  see 
[HJL96a].) 

To  demonstrate  the  properties  we  would  like  to  es¬ 
tablish,  we  consider  the  following  properties  for  the 
safety  injection  specification: 

1.  Reset  =  On  A  Pressure  ^  High  =>•  ^Overridden 

2.  Reset  =  On  A  Pressure  =  TooLow  =>• 

Saf etylnjection =  On 

3.  Block  =  Off  A  Pressure  =  TooLow  =>• 

Saf etylnjection =  On 

3.1  Establishing  Invariants 

To  establish  a  formula  q  as  an  invariant  of  a  state 
machine,  we  need  to  show  that  q  holds  in  every  reach¬ 
able  state  of  the  machine.  We  do  this  by  starting 
from  the  initial  state  and  repeatedly  computing  the 
next  states  until  a  Hxpoint  is  reached.  To  compute 
the  possible  new  states  given  a  current  state,  we  need 
representations  of  the  transform  T  and  of  the  input 
events  that  trigger  the  state  transitions.  Recall  that 
the  system  transform  T  (which  specifies  the  new  val¬ 
ues  of  system  entities)  is  deterministic,  whereas  the 
state  machines  for  monitored  variables  are  nondeter¬ 
ministic.  The  nondeterminism  has  two  aspects:  (a) 
more  than  one  monitored  variable  may  change  (i.e., 
is  enabled)  and  (b)  a  given  monitored  variable  may 
change  in  more  than  one  way. 

To  compute  the  next  states,  we  associate  with  each 
entity  rq  in  RF,  a  conditional  assignment  of  the  form: 

if 


□ 

9i,  1 

—>  Vi 

■  =  vit  1 

□ 

9i,  2 

— ►  n 

:=  Vi,  2 

□ 

9i,n 

,  — >■  n 

:=  Vi. 

fi 


Here,  9i,i,  9i,2,  ■  ■  ■ ,  9i,n,  are  boolean  expressions 
(guards)  and  r’gi,  1^2,  •  •  • ,  Vi,m  are  expressions  that 
are  type  compatible  with  entity  r;.  We  define  the  se¬ 
mantics  of  a  conditional  assignment  along  the  lines  of 
the  enumerated  assignment  of  UNITY  [CM88]  -  one 


assignment  whose  associated  guard  is  “true”  is  exe¬ 
cuted  at  each  transition.  If  more  than  one  guard  is 
“true” ,  then  any  one  of  the  associated  assignments 
is  nondeterministically  chosen.  If  no  guard  is  “true” , 
the  entity  value  is  left  unchanged.  To  represent  the 
functions  defined  by  SCR  tables,  we  allow  the  expres¬ 
sions  gi,i,gi,2,---,gi,m  and  vitl,  vi)2) . . . ,  to  refer 
to  both  “old”  and  “new”  values  of  entities,  provided 
that  the  “new”  references  are  not  circular. 

For  the  control  system  example,  the  conditional 
assignment  for  the  term  Overridden  is  given  below. 
Conditional  assignments  for  entities  Pressure  and 
Saf  etylnj  ection  can  be  expressed  in  a  similar  fash¬ 
ion. 

if 

□  (Pressure=TooLow)  AND  @T(Block=0n)  AND 

(Reset=0ff)  ->  Overridden  :=  true 

□  (Pressure=Permitted)  AND  @T(Block=0n)  AND 

(Reset=0ff)  ->  Overridden  :=  true 

□  @T(Pressure=High) 

->  Overridden  :=  false 

□  @T( (Pressure=TooLow)  OR  (Pressure=Permitted) ) 

->  Overridden  :=  false 

□  (Pressure=TooLow)  AND  @T(Reset=0n) 

->  Overridden  :=  false 

□  (Pressure=Permitted)  AND  @T(Reset=0n) 

->  Overridden  :=  false 
fi 

The  following  is  the  conditional  assignment  for  the 
monitored  variable  Block.  Conditional  assignments 
for  the  monitored  variables  WaterPres  and  Reset  can 
be  expressed  in  a  similar  fashion. 

if 

□  (Block=0ff )  ->  Block  :=  On 

□  (Block=0n)  ->  Block  :=  Off 

fi 

Given  a  current  state  s  and  the  conditional  assign¬ 
ments  for  all  monitored  variables,  we  can  determine 
the  set  of  input  events  that  are  enabled  in  s  by  evalu¬ 
ating  each  guard.  Each  guard  that  evaluates  to  “true” 
along  with  the  associated  assignment  determines  an 
input  event  that  is  enabled  in  s.  Because  the  One 
Input  Assumption  only  allows  a  single  input  event 
to  occur  at  each  transition,  one  of  the  enabled  input 
events  e  is  selected  nondeterministically. 

The  selected  input  event  e  and  the  current  state  s 
determine  the  new  state  s' .  Because  the  transform  T 
is  a  function,  s'  is  unique.  The  values  of  the  monitored 
variables  in  the  new  state  s'  are  determined  solely  by 


the  input  event  e.  The  values  of  the  other  entities 
in  the  new  state  s'  (the  mode  classes,  the  terms,  and 
the  controlled  variables)  can  be  computed  from  the 
conditional  assignments  for  these  entities.  The  par¬ 
tial  order  determines  the  sequence  in  which  the  con¬ 
ditional  assignments  are  evaluated.  Because  a  total 
function  defines  the  value  of  each  mode  class,  term, 
and  controlled  variable,  only  one  guard  of  each  condi¬ 
tional  assignment  will  evaluate  to  “true”  and  only  one 
assignment  can  be  executed  per  entity. 


4  State  Space  Reduction 

Model  checking  may  be  ineffective  in  practice  be¬ 
cause  of  state  explosion.  By  their  very  nature,  the 
number  of  reachable  states  of  practical  systems  is  usu¬ 
ally  very  large  in  relation  to  their  logical  representa¬ 
tion.  Therefore,  most  Hxpoint  computations  fail  to 
terminate  (by  running  out  of  memory)  for  realistic 
specifications. 

Several  techniques  are  proposed  in  the  literature  for 
limiting  state  explosion.  The  technique  we  use  to  con¬ 
tain  state  explosion  is  abstraction  -  instead  of  model 
checking  a  full  SCR  specification,  we  model  check  a 
smaller,  more  abstract  model.  To  derive  the  abstrac¬ 
tion,  we  exploit  the  structure  of  the  formula  and  the 
structure  inherent  in  all  SCR  specifications.  Below,  we 
state  two  correctness  preserving  reductions  that  derive 
a  more  abstract  model  from  an  SCR  specification.  We 
state  two  general  theorems  and  a  corollary  which  de¬ 
scribe  the  conditions  under  which  an  invariant  of  the 
more  abstract  model  is  also  an  invariant  of  the  full 
SCR  specification. 

In  the  theorems  and  corollary  below,  we  use  two 
predicates  to  characterize  the  initial  state  s o  and  the 
transform  T  of  a  state  machine  £  =  (S,  so,  Em ,  T).  To 
characterize  the  initial  state  s o ,  we  define  a  predicate 
0  such  that  0(s)  is  true  iff  s  =  s0-  To  characterize 
the  allowed  state  transitions,  we  define  a  predicate  p 
on  pairs  of  states  such  that  p(s,s')  is  true  iff  there 
exists  an  enabled  event  e  £  Em  such  that  T(e,  s)  =  s' . 

Given  two  state  machines  and  a  mapping  between 
their  states,  the  first  theorem  describes  conditions 
which  guarantee  that  a  predicate  formula  which  holds 
in  a  state  of  one  machine  also  holds  in  the  correspond¬ 
ing  state  of  the  second  machine.  The  second  theorem 
states  conditions  which  guarantee  that  an  invariant  of 
one  machine  is  also  an  invariant  for  a  second  machine. 
Finally,  the  corollary  combines  the  two  theorems  to 
give  general  conditions  which  guarantee  that  an  in¬ 
variant  of  one  machine  is  also  an  invariant  of  a  second 
machine. 


Theorem  4.1  Consider  two  finite  state  machines,  Y 
and  Ya,  with  entity  sets  RF  and  RFa,  type  functions 
TY  and  TYa,  and  state  sets  S  and  Sa  between  which 
there  is  a  mapping  s  sa-  Suppose  (a)  RFa  C  RF , 

(b)  for  all  r  £  RFa  :  TYa{t)  =  TY(r),  (c)  msj  is 
a  mapping  such  that  for  all  r  £  RFa :  sa(t)  =  s(r), 
and  (d)  q  is  any  predicate  formula  defined  over  RFa ■ 
Then,  if  q  holds  for  state  s a,  then  q  also  holds  for  state 
s,  that  is,  q(sA)  =S  q(s). 

Theorem  4.2  Consider  two  finite  state  machines,  Y 
and  Ya,  with  state  sets  S  and  Sa  between  which  there 
is  a  mapping  s  s a,  initial  state  predicates  0  and 
0A,  and  next  state  predicates  p  and  pa-  Suppose  (a) 
s  i — >  sa  is  a  mapping  such  that  for  all  r  £  RFa : 
su(t)  =  s(r),  (b)  for  all  s  m  S:  0(s)  =>•  0a(«a)> 

(c)  for  alls,  s'  m  S:  p(s,sr)  =>•  Pa{sa,s'a),  and  (d) 
q  is  any  predicate  formula  over  RFa  such  that  for  all 
sa  £  Sa-'  q(sa)  =S  q(s).  Then,  if  q  is  an  invariant  of 
Ya,  then  q  is  also  an  invariant  ofY. 

Corollary  4.3  If  the  hypotheses  of  Theorems  fil  and 
4-2  hold,  then  any  predicate  formula  q  over  RFa  that 
is  an  invariant  o}Ya  is  also  an  invariant  ofY. 

Presented  below  are  two  principles  we  can  use  to  de¬ 
rive  a  more  abstract  SCR  specification  from  a  full  SCR 
specification.  By  applying  these  principles,  we  elimi¬ 
nate  certain  entities  and  their  associated  tables  from 
the  full  SCR  specification.  Instead  of  model  checking 
the  full  specification  of  the  state  machine  Y,  we  model 
check  an  abstract  SCR  specification  of  state  machine 
Ya-  Because  the  transformations  we  apply  to  derive 
the  abstract  machine  Ya  satisfy  the  conditions  in  the 
corollary,  any  invariant  we  prove  for  the  abstract  ma¬ 
chine  Ya  is  also  an  invariant  of  the  original  state  ma¬ 
chine  Y. 

4.1  Reduction  Principle  1:  Eliminate  Ir¬ 
relevant  Entities 

This  principle  uses  the  set  of  entity  names  which 
occur  in  the  formula  being  verified  to  eliminate  un¬ 
needed  entities  and  the  tables  that  define  them  from 
the  analysis.  To  apply  this  principle,  we  identify  the 
set  O  C  RF  of  entities  occurring  in  formula  q.  Then, 
we  let  set  O*  be  the  reflexive  and  transitive  closure  of 
O  under  the  dependency  relation  D  of  an  SCR  spec¬ 
ification  for  state  machine  Y.  It  is  sound  to  infer  the 
invariance  of  q  for  Y  if  q  is  an  invariant  of  the  abstract 
machine  Ya  with  RFa  =  O*  and  if  the  system  trans¬ 
form  of  Ya,  Ta,  is  obtained  from  T  by  deleting  all 
associated  tables  or  state  machines  for  entities  in  set 

RF  -  RFa. 


This  reduction  principle  is  also  complete  -  if  q  is 
an  invariant  of  a  finite  state  machine  Y,  and  Ya  is  an 
abstract  machine  derived  from  Y  by  the  application  of 
this  principle,  then  q  is  an  invariant  of  Ya-  In  other 
words,  we  will  always  be  able  to  establish  an  invari¬ 
ant  of  Y  by  model  checking  Ya-  Therefore,  we  always 
apply  this  reduction  automatically  before  every  verifi¬ 
cation. 

For  example,  suppose  we  are  establishing  the  invari¬ 
ance  of  formula  (1)  for  the  safety  injection  system.  We 
identify  the  set  of  entities  O  occurring  in  the  formula 
as 

O  =  {Pressure,  Overridden,  Reset}. 

The  reflexive  and  transitive  closure  of  O  under  the 
dependency  relation  D  for  safety  injection  is  O* ,  which 
is  defined  by 

O*  =  {Pressure,  Overridden,  Reset,  Block,  WaterPres}. 

Applying  the  reduction  principle,  we  eliminate  con¬ 
trolled  variable  Saf etylnj  ection,  together  with  its 
table,  for  model  checking  property  (1). 

Applying  this  principle  reduces  the  size  of  the  state 
space  in  two  ways.  Recall  that  each  state  s  of  state 
machine  Y  is  a  function  that  maps  each  entity  in  RF 
to  its  value  in  s.  When  model  checking  Y,  we  store  the 
values  of  all  entities  for  each  state  s  in  E’s  state  space. 
For  the  corresponding  abstract  machine  Ya,  we  are 
only  required  to  store  values  of  entities  in  O*  C  RF 
for  each  state  in  E^’s  state  space,  which  reduces 
the  memory  requirement  for  storing  each  state.  In  ad¬ 
dition,  states  of  Y  that  map  entities  in  O*  to  identical 
values  will  be  represented  as  a  single  state,  which  re¬ 
duces  the  number  of  states  in  the  state  space. 

4.2  Reduction  Principle  2:  Monitored 
Variable  Abstraction 

This  principle  uses  more  abstract  representations 
of  monitored  variables  for  model  checking.  To  accom¬ 
plish  this,  we  identify  a  set  of  entities  O  C  RF  of 
the  state  machine  Y  described  by  an  SCR  specifica¬ 
tion.  These  entities  may  or  may  not  occur  in  for¬ 
mula  q.  Let  set  O*  be  the  reflexive  and  transitive 
closure  of  O  under  the  dependency  relation  D  for  Y. 
We  require  (a)  for  each  entity  rq  £  RF  —  O* ,  and 
r-j  £  O*  —  O',  (rq,  rj)  D,  and  (b)  entities  in  O*  —  O 
do  not  occur  in  formula  q.  It  is  sufficient  to  verify  the 
invariance  of  q  for  the  abstract  state  machine  Ya  with 
RFa  =  RF  —  ( O *  —  O)  and  with  the  system  transform 
Ta,  which  is  obtained  from  T  by  deleting  all  associated 
tables  or  state  machines  of  entities  in  O* .  By  doing 
this,  we  associate  with  each  entity  e  £  O,  the  “most 


general”  state  machine2. 

This  principle  identifies  an  abstract  machine  whose 
“monitored  quantities”  are  entities  in  O.  The  values 
of  these  entities  in  a  new  state  may  depend  on  the 
values  of  other  entities  in  the  original  specification, 
which  we  eliminate  in  the  abstracted  version.  We 
therefore  allow  entities  in  O  to  be  modified  by  the 
(new)  “environment”  of  the  abstract  machine,  which 
causes  new  “input  events” .  It  is  easy  to  see  that  a 
property  that  holds  under  weaker  assumptions  about 
the  abstract  machine’s  “environment”  also  holds  for 
the  original  specification  under  stronger  assumptions 
about  the  (real)  environment  of  the  system. 

The  root  cause  of  state  explosion  when  model  check¬ 
ing  safety  injection  is  monitored  variable  WaterPres. 
We  therefore  wish  to  eliminate  this  monitored  vari¬ 
able.  We  observe  that  WaterPres  only  appears  in  the 
table  for  mode  class  Pressure.  Therefore,  we  let  O  = 
{Pressure}.  The  reflexive  and  transitive  closure  of  O 
under  the  dependency  relation  D  for  safety  injection 
is  O*  =  {Pressure,  WaterPres}.  Since  WaterPres 
does  not  occur  in  any  formula  (1)  to  (3),  nor  in  the 
tables  for  entities  Overridden  and  Saf  etylnj  ection, 
we  may  delete  WaterPres,  and  the  table  for  entity 
Pressure  when  model  checking  formulae  (1)  to  (3). 
By  deleting  the  table  for  entity  Pressure,  we  asso¬ 
ciate  with  Pressure  a  state  machine  with  initial  state 
TooLow,  the  set  {TooLow,  Permitted,  High.}  as  the 
possible  states,  and  whose  next  state  relation  is  the 
largest  binary  relation  on  this  set. 

Unlike  Reduction  Principle  1,  this  principle  is  not 
complete.  This  is  because  there  are  “extra”  transitions 
for  state  machine  T,a  which  generate  states  that  are 
excluded  from  the  mapping  s  h- >  That  is,  the  map 

s  h- >  is  no  longer  onto. 

5  Using  the  Spin  Verifier 

Spin  [Hol91]  is  a  model  checker  which  uses  state 
exploration  for  verifying  properties.  Systems  are  de¬ 
scribed  in  a  language  called  Promela,  and  properties 
are  expressed  in  linear-time  temporal  logic  [MP91b]. 
Spin  has  been  used  to  verify  communication  protocols 
and  asynchronous  hardware. 

Promela,  the  language  of  Spin,  is  a  notation 
loosely  based  on  Dijkstra’s  “guarded  commands” 
[Dij 7 6] .  Supported  data  types  in  Promela  include 
bool  (booleans),  byte  (short  unsigned  integers),  and 
int  (signed  integers).  Control  statements  include  the 
assignment  statement,  statement  skip  (which  does 

2  A  machine  with  states  TY (e),  whose  transition  relation  is 
characterized  by  the  predicate  “true”  . 


nothing),  sequential  composition  of  statements,  the 
conditional  statement,  and  the  iterative  statement. 
The  language  also  has  an  assert  statement. 

Translating  an  SCR  specification  to  Promela  pro¬ 
ceeds  as  follows.  Because  Promela  does  not  allow  ex¬ 
pressions  to  refer  to  both  “old”  and  “new”  values  of 
variables,  we  assign  two  Promela  variables  to  each  en¬ 
tity  in  the  SCR  specification.  We  call  these  the  “new” 
and  “old”  variables.  Further,  expressions  contain¬ 
ing  the  event  notation  @T(c)  must  be  translated  into 
equivalent  forms  involving  the  “old”  and  the  ’’new” 
variables.  We  translate  the  conditional  assignment  for 
each  table  into  a  Promela  conditional  statement,  which 
computes  the  value  of  the  “new”  variable  for  each  step. 
The  conditional  statements  are  executed  sequentially, 
in  a  predetermined  order  that  is  consistent  with  the 
partial  order  induced  by  the  new  state  dependency  re¬ 
lation  of  the  SCR  specification.  After  all  conditional 
assignments  for  table  functions  are  executed,  and  new 
values  assigned  to  all  “new”  variables,  all  the  “old” 
variables  are  assigned  their  corresponding  “new”  val¬ 
ues. 

Further,  we  perform  an  optimization  based  on  the 
fact  that  the  system  transform  of  an  SCR  specifica¬ 
tion  is  a  function.  This  ensures  that  all  conditional 
statements  for  entities  other  than  the  monitored  vari¬ 
ables  are  deterministic.  Therefore,  once  we  have  se¬ 
lected  an  input  event,  we  may  compute  the  new  state 
in  a  single  step.  In  Promela  we  specify  this  by  enclos¬ 
ing  all  the  statements  which  correspond  to  the  com¬ 
putation  of  the  mode  variables,  the  terms,  and  the 
controlled  variables  in  a  d_step  (deterministic  step) 
construct.  This  ensures  that  all  intermediate  states 
(i.e. ,  the  states  generated  after  each  assignment  to  the 
“new”  and  “old”  variables)  are  not  entered  in  the  hash 
table  which  stores  the  reachable  states. 

To  generate  Promela  code  corresponding  to  input 
events,  we  generate  a  (non-deterministic)  conditional 
statement  for  each  monitored  variable,  which  assigns 
any  value  (in  the  variable’s  domain)  to  the  “new” 
Promela  variable.  We  “build  in”  the  One  Input  As¬ 
sumption  by  embedding  all  assignments  to  monitored 
variables  in  a  single  (nondeterministic)  conditional 
statement. 

Assertion  checking  an  invariant  is  performed  by 
checking  for  its  truth  in  the  initial  state,  and  in  each 
generated  “new”  state,  by  embedding  it  in  a  Promela 
assert  statement. 

Appendix  A  presents  the  Promela  code  generated 
by  the  SCR*  toolset  (edited  to  enhance  readability) 
for  the  safety  injection  example. 


Specification 

Property 

Reduction 

States 

Time 

Memory 

d_step 

RP1 

RP2 

SIS 

(2) 

1.7  Million 

56s 

52  MBytes 

SIS 

(2) 

i/ 

459,084 

13s 

17  MBytes 

SIS 

(2) 

i/ 

632 

Os 

1.2  MBytes 

SIS 

(1) 

i/ 

V 

450 

Os 

1.2  MBytes 

SIS 

(1) 

i/ 

V 

V 

160 

Os 

1.2  MBytes 

Autopilot 

V 

oo 

- 

- 

Autopilot 

V 

i/ 

i/ 

i/ 

109,826 

3s 

3.6  MBytes 

Table  4:  Results  of  Verifying  SCR  Specifications  Using  Spin. 


5.1  A  Note  on  Partial  Order  Reduction 

In  contrast  to  conventional  partial  order  reduction 
methods  for  combating  state  explosion  [Val90,  God90, 
HP94],  which  compute  and  keep  track  of  informa¬ 
tion  about  redundant  interleavings  during  state  explo¬ 
ration  in  order  to  avoid  the  exploration  of  redundant 
interleavings,  it  is  sufficient  in  our  approach  to  eval¬ 
uate  the  system  transform  using  only  one  predeter¬ 
mined  interleaving  that  is  consistent  with  the  partial 
order  induced  by  the  new  state  dependency  relation. 
This  is  a  property  common  to  all  SCR  specifications, 
which  follows  from  the  SCR  formal  model.  Therefore, 
enabling  Spin’s  partial  order  reduction  algorithm  will 
almost  never  reduce  the  space  requirement,  and  may 
increase  the  time  requirement  for  verification  (due  to 
additional  overhead). 

5.2  Limitations  of  using  Spin 

Declaring  “old”  and  “new”  Promela  variables  for 
each  entity  of  an  SCR  specification  can  potentially  in¬ 
crease  the  state  space  by  an  exponential  factor.  An¬ 
other  problem  we  encountered  was  in  translating  coun¬ 
terexamples  generated  by  Spin  to  the  format  of  our 
toolset.  This  is  particularly  hard  when  we  use  abstrac¬ 
tions  during  model  checking.  Generating  understand¬ 
able  counterexamples  is  an  important  requirement  for 
our  toolset.  For  these  reasons,  we  concluded  that  one 
way  to  seamlessly  integrate  model  checking  into  the 
toolset  may  be  to  implement  a  special  purpose  model 
checker  for  SCR. 

6  Results 

In  this  section,  we  present  the  results  of  some  of  our 
verification  experiments.  To  evaluate  the  translation 
method  and  reduction  principles  outlined  in  this  pa¬ 
per,  we  have  applied  them  to  several  “toy”  examples, 
and  to  a  more  “industrial-strength”  SCR  specification. 


For  the  safety  injection  specification  (SIS),  we  were 
able  to  establish  properties  (1)  and  (2).  We  also 
showed  that  property  (3)  is  not  an  invariant  of  the 
specification.  One  of  the  major  problems  in  using 
model  checking  to  evaluate  abstract  models  is  that 
counterexamples,  which  are  generated  in  terms  of  the 
abstractions,  are  usually  hard  to  interpret.  We  had 
no  difficulty  in  interpreting  counterexamples  gener¬ 
ated  for  abstractions  of  SCR  specifications,  because 
they  are  couched  in  terms  of  entities  in  the  original 
specification.  We  view  this  as  an  important  advan¬ 
tage  of  our  reduction  principles. 

We  recently  used  the  SCR  method  to  produce 
a  black  box  requirements  specification  of  a  simpli¬ 
fied  mode  control  panel  for  the  Boeing  737  autopi¬ 
lot  [BH96] .  The  verification  method  presented  in  this 
paper  proved  to  be  valuable  in  detecting  and  correct¬ 
ing  bugs  in  the  autopilot  specification.  The  specifica¬ 
tion  is  fairly  large,  consisting  of  more  than  a  dozen 
tables.  More  important,  the  specification  is  infinite- 
state,  since  it  contains  three  real-valued  monitored 
variables.  Hence,  it  would  have  been  impossible  to 
model  check  the  specification  had  we  not  applied  our 
reduction  principles. 

We  were  initially  unable  to  model  check  the  au¬ 
topilot  specification  even  after  we  applied  the  reduc¬ 
tion  principles,  raising  questions  in  our  minds  about 
their  scalability.  However,  by  model  checking,  we  were 
able  to  find  a  violation  of  the  property,  “The  alti¬ 
tude  engage  mode  will  be  armed  only  when  the  flight- 
path  angle  select  mode  is  engaged”  (property  V  in  Ta¬ 
ble  4).  The  generated  counterexample  was  a  sequence 
of  roughly  half  a  million  states.  Interpreting  the  coun¬ 
terexample  did  not  turn  out  to  be  too  difficult,  since 
we  were  able  to  understand  the  counterexample  merely 
by  examining  the  input  event  that  led  to  the  bad  state. 
Interestingly,  the  corrected  specification  had  far  fewer 
states  and  model  checked  without  difficulty. 

Table  4  presents  some  of  our  results.  In  Table  4, 
reduction  d_step  refers  to  the  optimization  where  we 


enclose  all  the  statements  corresponding  to  the  com¬ 
putation  of  the  dependent  variables  (the  mode  classes, 
the  terms,  and  the  controlled  variables)  in  a  Promela 
d_step  (deterministic  step)  statement.  Reductions 
RP1  and  RP2  refer  to  the  two  reduction  principles. 
The  symbol  ‘oo’  in  the  table  means  that  Spin  ran  out 
of  memory  before  it  could  complete  its  evaluation  of 
the  given  property. 

We  ran  these  experiments  on  a  lightly 
loaded  75  MHz  dual-processor  SPARCstation-20  with 
128MBytes  of  RAM.  Our  tool  built  the  conditional  as¬ 
signments  automatically  from  the  SCR  requirements 
specifications.  Moreover,  the  partial  order  derived  by 
the  tool  determined  the  sequence  in  which  the  con¬ 
ditional  assignments  were  executed.  The  reduction 
principles  were  applied  manually.  The  abstract  mod¬ 
els  produced  were  then  analyzed  automatically  by  the 
toolset  using  Spin. 

7  Conclusions  and  Future  Work 

State  exploration  based  model  checking  can  be  used 
to  analyze  moderately  large  requirements  specifica¬ 
tions.  However,  because  most  requirements  specifi¬ 
cations  are  necessarily  too  detailed,  model  checking  is 
only  feasible  for  abstractions  of  the  specifications.  In 
previous  approaches,  the  correspondence  between  an 
abstraction  and  the  original  requirements  specification 
has  been  informal  -  the  correctness  of  the  abstraction 
was  based  on  intuitive  arguments.  In  this  paper,  we 
describe  a  formal  framework  and  two  reduction  princi¬ 
ples  for  deriving  an  abstraction  from  an  SCR  require¬ 
ments  specification  and  the  formula  to  be  verified.  The 
theorems  and  corollary  in  Section  4  guarantee  that  an 
invariant  that  holds  for  the  abstraction  also  holds  for 
the  full  SCR  specification.  We  have  applied  our  re¬ 
duction  principles  to  several  “toy”  examples  and  to 
a  more  “industrial  strength”  requirements  specifica¬ 
tion.  Our  initial  experiments  with  the  state  enumera¬ 
tion  tool  Spin  strongly  suggest  that  our  principles  can 
be  used  to  combat  state  explosion  in  verifying  specifi¬ 
cations  of  practical  systems. 

In  its  current  form,  our  principle  for  abstracting 
monitored  variables  is  incomplete,  since  we  model 
check  under  assumptions  that  are  weaker  than  the  as¬ 
sumptions  about  the  environment  in  the  original  spec¬ 
ification.  We  would  like  to  explore  techniques  such  as 
homomorphic  reduction  [Kur89],  simulation  mappings 
[Lyn94],  and  abstract  interpretation  [AD90]  to  either 
verify  stronger  abstractions  (provided  by  users)  or  de¬ 
rive  abstractions  from  the  requirements  specification. 

In  this  paper,  we  perform  a  static  optimization 


based  on  the  partial  order  defined  by  the  dependency 
relation  of  an  SCR  specification.  In  contrast  to  con¬ 
ventional  partial  order  reduction  methods,  whose  ben¬ 
efits  are  diminished  due  to  additional  space  and  time 
overhead  during  verification,  our  approach  has  the  ad¬ 
vantage  of  not  introducing  any  overhead  during  state 
exploration. 

We  plan  to  develop  tools  that  apply  our  reduction 
techniques  automatically.  Another  goal  is  tighter  inte¬ 
gration  of  counterexample  generation  and  interpreta¬ 
tion  with  existing  tools  (such  as  the  simulator)  in  our 
toolset.  We  also  plan  to  use  other  methods  for  veri¬ 
fying  SCR  requirements  specifications,  including  sym¬ 
bolic  model  checking  using  binary  decision  diagrams 
and  mechanical  theorem  proving. 
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A  Promela  code  for  safety  injection 


/*  This  file  contains  the  PROMELA/spin  version  of  an  SCRTool  specification.  */ 
/*  It  is  created  by  SCRTool  and  automatically  fed  to  Xspin.  */ 

/*  However,  this  file  was  left  in  the  file  sis. spin  */ 

/*  for  you  to  use,  look  at,  etc.  */ 


/*  numeric  constants  */ 

bool  TRUE  =  1; 
bool  FALSE  =  0; 

#define  TooLow  0 
#define  Permitted  1 
#define  High  2 
#define  On  0 
#define  Off  1 
#define  Low  900 
#define  Permit  1000 


/*  variable  declarations  */ 

byte  Block  =  Off; 
byte  BlockP  =  Off; 
bool  Overridden  =  FALSE; 
bool  OverriddenP  =  FALSE; 
byte  Reset  =  On; 
byte  ResetP  =  On; 
byte  Saf etylnj ection  =  On; 
byte  Saf etylnj ectionP  =  On; 
int  WaterPres  =  14; 
int  WaterPresP  =  14; 
byte  Pressure  =  TooLow; 
byte  PressureP  =  TooLow; 


/*  init  function  */ 

init  { 

/*  main  processing  loop  */ 
do 


/*  specification  asserts  */ 

/*  (Reset  =  On  AID  Pressure  =  TooLow)  =>  Saf etylnj ection  =  On  */ 
assert ((!( (Reset  ==  On)  &&  (Pressure  ==  TooLow)))  II  (Saf etylnj ection 


On)) 


/*  simulation  of  monitored  variable  changes;  do  one  each  pass  */ 
if 

:  :  if 

/*  randomly  select  any  value  except  the  current  one  */ 

::  (Block  !=  On)  ->  BlockP  =  On  ; 

::  (Block  !=  Off)  ->  BlockP  =  Off  ; 
fi 
:  :  if 

/*  randomly  select  any  value  except  the  current  one  */ 


fi 
:  :  if 


(Reset  !=  On) 

-> 

ResetP  = 

On  ; 

(Reset  !=  Off) 

>  ResetP  = 

=  Off  ; 

randomly  jump 

to 

any  value  within  the  legal  range  of  the 

( (WaterPres 

+ 

1) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

1 

( (WaterPres 

- 

1) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  1 

> 

( (WaterPres 

+ 

2) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

2 

( (WaterPres 

- 

2) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  2 

> 

( (WaterPres 

+ 

3) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

3 

( (WaterPres 

- 

3) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  3 

> 

( (WaterPres 

+ 

4) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

4 

( (WaterPres 

- 

4) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  4 

> 

( (WaterPres 

+ 

5) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

5 

( (WaterPres 

- 

5) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  5 

> 

( (WaterPres 

+ 

6) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

6 

( (WaterPres 

- 

6) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  6 

> 

( (WaterPres 

+ 

7) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

7 

( (WaterPres 

- 

7) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  7 

> 

( (WaterPres 

+ 

8) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

8 

( (WaterPres 

- 

8) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  8 

> 

( (WaterPres 

+ 

9) 

<=  2000) 

->  WaterPresP 

=  WaterPres  + 

9 

( (WaterPres 

- 

9) 

>=  0)  -> 

WaterPresP  = 

WaterPres  -  9 

> 

::  ((WaterPres  +  10)  <=  2000)  ->  WaterPresP  =  WaterPres  +  10  ; 

::  ((WaterPres  -  10)  >=  0)  ->  WaterPresP  =  WaterPres  -  10  ; 
fi 
fi; 

/*  executions  of  the  functions  in  dependency  order  */ 

/*  the  PROMELA  version  of  the  Pressure  function  */ 

d_step{ 

if 

/*  modes:  TooLow  */ 

/*  event:  ®T(WaterPres  >=  Low)  */ 

::  (((! (WaterPres  >  Low))  &&  ((Pressure  ==  TooLow)  && 

(! (WaterPres  ==  Low))))  &&  (WaterPresP  >  Low)) 

II  (((! (WaterPres  ==  Low))  &&  ((Pressure  ==  TooLow)  && 

(! (WaterPres  >  Low))))  &&  (WaterPresP  ==  Low)) 

->  PressureP  =  Permitted; 

/*  modes:  Permitted  */ 

/*  event:  ®T(WaterPres  <  Low)  */ 

::  (((! (WaterPres  <  Low))  &&  (Pressure  ==  Permitted))  &&  (WaterPresP  <  Low)) 
->  PressureP  =  TooLow; 

/*  modes:  Permitted  */ 

/*  event:  ®T(WaterPres  >=  Permit)  */ 

::  (((! (WaterPres  >  Permit))  &&  ((Pressure  ==  Permitted)  && 

(! (WaterPres  ==  Permit))))  &&  (WaterPresP  >  Permit)) 

II  (((! (WaterPres  ==  Permit))  &&  ((Pressure  ==  Permitted)  && 

(! (WaterPres  >  Permit))))  &&  (WaterPresP  ==  Permit)) 

->  PressureP  =  High; 

/*  modes:  High  */ 

/*  event:  ®T(WaterPres  <  Permit)  */ 

::  (((! (WaterPres  <  Permit))  &&  (Pressure  ==  High))  &&  (WaterPresP  <  Permit)) 
->  PressureP  =  Permitted; 

: :  else  skip; 

fi; 


/*  the  PROMELA  version  of  the  Overridden  function  */ 
if 

/*  modes:  TooLow,  Permitted  */ 

/*  event:  ®T(Block  =  On)  WHEN  Reset  =  Off  */ 

::  (((! (Block  ==  On))  &&  (((Pressure  ==  TooLow)  II 

(Pressure  ==  Permitted))  &&  (Reset  ==  Off)))  &&  (BlockP  ==  On)) 

->  OverriddenP  =  TRUE; 

/*  modes:  High  */ 

/*  event:  ®T( Inmode)  */ 

::  ((!(Pressure  ==  High))  &&  (PressureP  ==  High))  ->  OverriddenP  =  FALSE; 
/*  modes:  TooLow,  Permitted  */ 

/*  event:  ®T(Inmode)  OR  ®T(Reset  =  On)  */ 

::  ((!( (Pressure  ==  TooLow)  II  (Pressure  ==  Permitted)))  && 


((PressureP  ==  TooLow)  II  (PressureP  ==  Permitted))) 

II  (((! (Reset  ==  On))  &&  ((Pressure  ==  TooLow)  II 

(Pressure  ==  Permitted)))  &&  (ResetP  ==  On))  ->  OverriddenP  =  FALSE; 
: :  else  skip; 

fi; 


/*  the  PROMELA  version  of  the  Saf etylnj ection  function  */ 
if 

/*  modes:  High,  Permitted  */ 

/*  condition:  TRUE  */ 

::  ((PressureP  ==  High)  II  (PressureP  ==  Permitted))  ->  Saf etylnj ectionP  =  Off 
/*  modes:  TooLow  */ 

/*  condition:  Overridden  */ 

::  ((PressureP  ==  TooLow)  &&  OverriddenP)  ->  Saf etylnj ectionP  =  Off; 

/*  modes:  TooLow  */ 

/*  condition:  Hot  Overridden  */ 

::  ((PressureP  ==  TooLow)  &&  (! OverriddenP) )  ->  Saf etylnj ectionP  =  On; 

fi; 


/*  update  each  variable  and  mode  class  for  this  state  change  */ 

Block  =  BlockP;  Overridden  =  OverriddenP; 

Reset  =  ResetP;  Saf etylnj ection  =  Saf etylnj ectionP ; 

WaterPres  =  WaterPresP;  Pressure  =  PressureP; 

> 

od  /*  end  of  main  processing  loop  */ 


> 


